Atlas ATS
How we designed a new applicant tracking system where AI agents save recruiters' time - from product strategy to agent concept.
Atlas is a recruitment tech company that runs a popular job board - a website where employers post job ads and candidates apply. The company offered a simple, free tool for viewing applications, but it was too basic. Bigger clients kept switching to competitors with full applicant tracking systems (ATS) - software that manages the whole hiring process, from receiving applications to making an offer.
Atlas decided to build something more ambitious: a product where AI agents take over the repetitive work that eats recruiters' time. This was the key idea and the main innovation on the market - not AI as a marketing label, but agents built into the recruiter's daily workflow.
I was part of the expert team shaping this product from day one.
- Team - a small group of senior experts: product, design, engineering, business.
- Format - weekly, multi-hour strategy workshops where we defined the product concept, direction, and priorities.
The core of this project was the weekly workshop rhythm. Every week, the expert team spent several hours in one room working through product strategy: what this ATS should be, who it serves, and where AI genuinely helps. Between workshops, smaller groups explored specific topics and brought conclusions back to the table.
Our decisions were grounded in three types of research:
- Competitive research - qualitative studies of three different ATS products, deliberately different from each other in size, target clients, and approach. This gave us a real map of the market instead of one reference point.
- Internal research with recruiters - interviews with people who run recruitment every day. This is where we learned which tasks actually consume their time.
- Prototype testing - we didn't settle big design debates by opinion. When the team disagreed on a direction, we built prototypes and tested them with users.
The research gave us clear personas with very different needs.
This split shaped the whole product: one system, but different views and permissions per role.
This was the most important design work of the project. The question we kept asking: where does a recruiter lose time, and can an agent take that work over? Every agent had to answer a real problem from our research - no agent just because AI is trendy. I owned the concept and interaction design for each agent below, translating the team's research findings into specific product decisions.
The product launches in two versions with fundamentally different pricing.
- The free plan is tied to the job board: post a job ad, and a recruitment workspace appears automatically. It's free - but users can buy individual premium features for a limited time when they need them (e.g. custom form questions for one recruitment).
- The Pro plan is a monthly subscription: multiple parallel recruitments, full form customization, publishing to external boards, and the complete agent layer.
Working through these two versions, I noticed the two user groups think in opposite ways. Free users come to post an ad - the workspace should just appear in the background. Pro users start from the recruitment itself and then decide where to publish. Instead of forcing one flow on both, we treated this as two hypotheses and tested them with prototypes.
The pricing details turned out to be design decisions too. For example: the Pro plan limits how many recruitments can run at once. When does one "count" against the limit - when it's created, or when it starts collecting candidates? Each answer changes user behavior, so we flagged it for testing rather than deciding in a meeting room.
